|
INTRODUCTION
Although the 2004 Guide to the Software Engineering
Body of Knowledge is a milestone in reaching a broad agreement on the
content of the software engineering discipline, it is not the end of the
process. The 2004 Guide is simply the current edition of a guide that
will continue evolving to meet the needs of the software engineering community.
Planning for evolution is not yet complete, but a tentative outline of
the process is provided in this section. As of this writing, this process
has been endorsed by the project's Industrial Advisory Board and briefed
to the Board of Governors of the IEEE Computer Society, but is not yet
either funded or implemented.
STAKEHOLDERS
Widespread adoption of the SWEBOK Guide has
produced a substantial community of stakeholders in addition to the Computer
Society itself. There are a number of projects-both inside and outside
the Computer Society-that are coordinating their content with the content
of the SWEBOK Guide. (More about that in a moment.) Several corporations,
including some of the members of the project's Industrial Advisory Board,
have adopted the Guide for use in their internal programs for education
and training. In a broader sense, the software engineering practitioner
community, professional development community, and education community
pay attention to the SWEBOK Guide to help define the scope of their efforts.
A notable stakeholder group is the holders of the IEEE Computer Society's
certification-Certified Software Development Professional-because the
scope of the CSDP examination is largely aligned with the scope of the
SWEBOK Guide.
The IEEE Computer Society and other organizations are now conducting a
number of projects that have a dependency on the evolution of the SWEBOK
Guide:
- The CSDP examination, initially developed
in parallel with the SWEBOK Guide, will evolve to a close match to the
Guide-both in scope and reference material.
- The Computer Society's Distance Learning
curriculum for software engineers will have the same scope as the SWEBOK
Guide. An initial overview course is already available.
- Although the goals of undergraduate education
differ somewhat from those of professional development, the joint ACM/IEEE-CS
project to develop an undergraduate software engineering curriculum,
is largely reconciled with the scope of the SWEBOK Guide.
- The IEEE-CS Software Engineering Standards
Committee (SESC) has organized its collection by the knowledge areas
of the SWEBOK Guide, and the IEEE Standards Association has already
published a CD-ROM collected edition of software engineering standards
that reflects that organization.
- ISO/IEC JTC1/SC7, the international standards
organization for software and systems engineering, is adopting the SWEBOK
Guide as ISO/IEC Technical Report 19759, and harmonizing its collection
with that of IEEE.
- The IEEE Computer Society Press, in cooperation
with SESC, is developing a book series based on software engineering
standards and the SWEBOK Guide.
- The Computer Society's Software Engineering
Portal, currently in planning, will be organized by the knowledge areas
of the SWEBOK Guide.
- The Trial Use Version of the SWEBOK Guide
was translated into Japanese. It is anticipated that the 2004 Version
will also be translated into Japanese, Chinese, and possibly other languages.
THE EVOLUTION PROCESS
Obviously, a product with this much uptake
must be evolved in an open, consultative, deliberate and transparent fashion
so that other projects can successfully coordinate efforts. The currently
planned strategy is to evolve the SWEBOK Guide using a "time-boxed"
approach. The time-box approach is selected because it allows the SWEBOK
Guide and coordinating projects to perform revision in anticipation of
a fixed date for convergence. The initial time-box is currently planned
to be four years in duration.
At the beginning of the time-box, in consultation with coordinating projects,
and overall plan for the four-year revision would be determined. During
the first year, structural changes to the SWEBOK Guide (e.g. changes in
number or scope of knowledge areas) would be determined. During the second
and third years, the selection and treatment of topics within the knowledge
areas would be revised. During the fourth year, the text of the knowledge
area descriptions would be revised and up-to-date references would be
selected.
The overall project would be managed by a Computer Society committee of
composed of volunteers and representatives of coordinating projects. The
committee would be responsible to set overall plans, coordinate with stakeholders,
and recommend approval of the final revision. The committee would be advised
by a SWEBOK Advisory Committee (SWAC) composed of organizational adopters
of the SWEBOK Guide. The SWAC would also be the focus for obtaining corporate
financial support for the evolution of the SWEBOK Guide. Past corporate
financial support has allowed us to make the SWEBOK Guide available for
free on a web site. Future support will allow us to continue the practice
for future editions.
Notionally, each of the four years would include a cycle of workshop,
drafting, balloting, and ballot resolution. A yearly cycle might involve
the following activities:
- A workshop, organized as a part of a major
conference, would specify issues for treatment during the coming year,
prioritize the issues, recommend approaches for dealing with them, and
nominate drafters to implement the approaches.
- Each drafter would write or modify a knowledge
area description using the approach recommended by the workshop and
available references. In the final year of the cycle, drafters would
recommend specific up-to-date references for citation in the SWEBOK
Guide. Drafters would also be responsible for modifying their drafts
in response to comments from balloters.
- Each annual cycle would include balloting
on the revisions to the knowledge area descriptions. Balloters would
review the drafted knowledge area descriptions and the recommended references,
provide comments, and vote approval on the revisions. Balloting would
be open to members of the Computer Society and other qualified participants.
(Non-members would have to pay a fee to defray the expense of balloting.)
Holders of the CSDP would be particularly welcome as members of the
balloting group, or as volunteers in other roles.
- A Ballot Resolution Committee would be
selected by the Managing Committee to serve as intermediaries between
the drafters and the balloters. Its job is to determine consensus for
changes requested by the balloting group and to ensure that the drafters
implement the needed changes. In some cases, the Ballot Resolution Committee
may phrase questions for the balloting group and use their answers to
guide the revision of the draft. Each year's goal is to achieve consensus
among the balloting group on the new and revised draft knowledge areas
and to gain a vote of approval from the balloters. Although the SWEBOK
Guide would not be changed until the end of the time box, the approved
material from each year's cycle will be made freely available.
At the conclusion of the time-box, the completed
product, SWEBOK Guide 2008, would be reviewed and approved by the Computer
Society Board of Governors for publication. If continuing corporate financial
support can be obtained, the product would be made freely available on
a web site.
ANTICIPATED CHANGES
It is important to note that the SWEBOK Guide
is inherently a conservative document for several reasons. First, it limits
itself to knowledge characteristic of software engineering; so information
from related disciplines-even disciplines applied by software engineers-is
omitted. Second, it is developed and approved by a consensus process;
so it can only record information for which broad agreement can be obtained.
Third, knowledge regarded as specialized to specific domains is excluded.
Finally and most importantly, the Guide records only the knowledge which
is "generally accepted." Even current and valid techniques may
need some time to gain general acceptance within the community.
This conservative approach is apparent in the current SWEBOK Guide. After
six years of work, it still has the same ten knowledge areas. One might
ask if that selection of knowledge areas will ever be changed. The plan
for evolution includes some criteria for adding a knowledge area or changing
the scope of a knowledge area. In principle, the candidate must be widely
recognized inside and outside the software engineering community as representing
a distinct area of knowledge and the generally accepted knowledge within
the proposed area must be sufficiently detailed and complete to merit
treatment similar to those currently in the SWEBOK Guide. In operational
terms, it must be possible to cleanly decouple the proposed knowledge
area from the existing ones and that decoupling must add significant value
to the overall taxonomy of knowledge provided by the Guide. However, simply
being a "cross-cutting" topic is not justification for separate
treatment because separation, in many cases, simply compounds the problem
of topic overlap. In general, growth in the total number of knowledge
areas is to be avoided when it complicates the efforts of readers to find
desired information.
Adding a topic to a knowledge area is easier. In principle, it must be
mature (or, at least, rapidly reaching maturity) and is must be generally
accepted . Evidence for general acceptance can be found in many places,
including software engineering curricula, software engineering standards,
and widely-used textbooks. Of course, topics must be suitable to the SWEBOK
Guide's design point of a bachelor's degree plus four years of experience.
That design point raises the issue of the volume of material referenced
by the SWEBOK Guide. The total amount of material should be consistent
with the design point of bachelor's degree plus four years of experience.
Currently, the editorial team estimates an appropriate amount to be 5000
pages of textbook material. During the evolution of the Guide, it will
be necessary to manage the lists of cited material so that references
are currently accessible, provide appropriate coverage of the knowledge
areas, and total to a reasonable amount of material.
A final topic is the role to be played by users of the SWEBOK Guide in
its evolution. The Editorial Team believes that continual public comment
is the fuel that will drive the evolution of the SWEBOK Guide. Public
comments will raise issues for treatment by the annual workshop, hence
setting the agenda for revision of the SWEBOK Guide. We hope to provide
a public, on-line forum for comment by any member of the software engineering
community and to serve as a focal point for adoption activities.
|